home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20041116-20060924 / 000247_slash_dev_slas…_2000@yahoo.com_Tue Feb 7 14:29:27 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Path: newsmaster.cc.columbia.edu!panix!news.linkpendium.com!news.linkpendium.com!news.glorb.com!postnews.google.com!f14g2000cwb.googlegroups.com!not-for-mail
  2. From: "Mark Sapiro" <slash_dev_slash_null_2000@yahoo.com>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: Modem hangup problem
  5. Date: 4 Feb 2006 07:55:40 -0800
  6. Organization: http://groups.google.com
  7. Lines: 25
  8. Message-ID: <1139068540.667200.46950@f14g2000cwb.googlegroups.com>
  9. References: <1138662868.847718.244330@f14g2000cwb.googlegroups.com>
  10.    <ZX3Ef.7306$JO5.3602@trnddc04>
  11. NNTP-Posting-Host: 209.182.169.133
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset="iso-8859-1"
  14. X-Trace: posting.google.com 1139068545 29306 127.0.0.1 (4 Feb 2006 15:55:45 GMT)
  15. X-Complaints-To: groups-abuse@google.com
  16. NNTP-Posting-Date: Sat, 4 Feb 2006 15:55:45 +0000 (UTC)
  17. User-Agent: G2/0.2
  18. X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20060111 Netscape/8.1,gzip(gfe),gzip(gfe)
  19. Complaints-To: groups-abuse@google.com
  20. Injection-Info: f14g2000cwb.googlegroups.com; posting-host=209.182.169.133;
  21.    posting-account=iQNWIg0AAAAD2fStXNC9nwGlPdSqjWrI
  22. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15495
  23.  
  24. Kelvin Smith wrote:
  25. >
  26. > Have you played with maximum packet sizes? I've found that sometimes
  27. > reducing the maximum size makes a borderline connection less likely to
  28. > choke. (SET RECEIVE PACKET n; you might want to try n=90 to start with.)
  29.  
  30. My understanding of the OP is that this is a straight text
  31. send/capture, not a protocol transfer, so things like packet size
  32. aren't relevant.
  33.  
  34. I'm guessing it's some kind of flow control issue. Maybe the receiver
  35. is choking and tries to stop the data and the sender keeps sending and
  36. eventually chokes the receiving modem buffer or something like that.
  37. Possibly reducing the speed of the sender will help if that's going to
  38. be an option in the real case. Or maybe 'set flow none' on the receiver
  39. which would result in data loss rather than a lost connection if this
  40. is the issue. Not a good thing, but it might help pinpoint the problem.
  41.  
  42. --
  43. (for email use this address please - you can figure it out)
  44.  
  45. Mark Sapiro msapiro -at- value net    Any clod can have the facts;
  46. San Francisco Bay Area, California    having opinions is an art. -
  47.                                       C. McCabe, The Fearless Spectator
  48.